Joystick Magazine 1995 November (Mac)/cd No7 joystick No65 novembre 1995.iso/mac/Fouillationnons!/Jeux/Xconq 7.0.1/doc/PROJECTS

Text File | 1995-08-23 | 118KB | 2,975 lines

PROJECT IDEAS

This list is a collection of ideas about what to change in Xconq.
In general, these are new features, rather than actual bug fixes.
Everything is grouped into one of several categories, although
the grouping is not precise, and to find out if some idea has been
already thought of, you should search this using appropriate keywords.

--Overall

Allow game to define the fate of units when a side resigns.  Default
should be for nothing to happen to any unit.  Possibilities include
disappearance, surrender to first unit showing up, whole side being
controlled, etc.
Also include policy or commands to edit the leftover images from
a losing side.

Set up consistent rules for action priority.
Unit action priority should be able to derive from individual extension
property, a per-side vector of type priorities, a per-type property,
and a per-side property.  Routine is just unit_priority(unit).
Goal is to be able to have, say, allied aircraft and German ground
units move together, then German aircraft and allied ground, then
trains and trucks of both sides.
Requirements:
1. Units of same priority should be able to be moved in a convenient
order (to minimize scrolling, according to player's prefs, etc).
2. All units of a given priority must have finished movement before
the next will move.  Includes delayed units.

--GDL

Define a global "side*" that is a list of all sides.

In evals, give meaning to "this" so expressions like (count <u> (this side))
work.

Could restrict some tables to 15 bit integers, use top bit to repn varying
value, up to 16d15+127 by doing a 4/4/7 split of bits.

Support full decimals for parms, flush the "10000" numbers and add scale
factor to all numeric parms.  Scaling fixed by code, use scaling when
computing effects.
Ambiguity if context of decimal doesn't include scale factor (as in "define"),
but could support decimals as a distinct type in GDL (as ratios instead of
floats?).  c_number should convert to integer, or check validity of uses.

Error messages should include context as well as line numbers (save previous
several lines, and dump next several if still reading after error).
Show first 72 chars of 3 previous lines and 3 following lines.

--Types and Objects

Fix see-always to not show city occupants unless explicitly set up.
(Only true of X11 interface?)

If the people in a cell change to a trusted side, or if a trusted unit
enters enemy cell, allies should get view updates.

Decide who will see terrain changes in general, and weather/season
effects.  Need always-seen for these things, use coverage arrays as well.
Also allow for varying reliability and completeness of this.

Implement delayed views, where a unit that is out of contact with the side
keeps own view data and only merges when in contact with side again.

[vision-terrain-effect to alter range depending on terrain?]

[check validity of random event list after loading]

/* (doctrine or general prefs specify what sorts of events get presented
   to players) */

For small-part-of-world areas, define daylight-zone and twilight-zone(?),
which default to 1/2 and 1/12 respectively.

Only certain types of units should be able to have mixed feelings, alloc
loyalty objects for these.  Loyalty objects all consistent size, needed only
if more than two feelings possible, else use 4-byte slot for values.
u_max_loyalties, default of 0 means like a machine, no issue of loyalty.
1 means always loyal to overt side, but degree can vary.
2 means overt and "true" side, be able to do with no extra space.
>2 possible, needs alloc.  Count indeps as one of sides.

Add area illumination ability so that burning wrecks and such can illuminate
immediate area at night.

Add a "last-alliance-wins" scorekeeper, use with some games.

Decide when sides should be able to look at other units' hp.

Climate-related global vars should become world or area properties.

Need a way to indicate that some types are never available in a game,
cache in arrays u_available[], etc, test internally, etc.
Also need a per-turn test to see what is currently available.

Notify display when cover goes to/from 0 (but excessive, since coverage
always cleared then restored later).

Add a controlled-by layer to world that can be distinct from people side.
Control can be imposed by presence of particular units within a given
range, maintained by others to a given range, with chance of reversion
to people side if different from controlling side.

Use unit->origside in reporting, liberation, etc.
Captured unit actually goes to origside if trusted by
capturing unit's side.

Define unit feelings toward each side as pair of bytes, for/against and
willingness to act on feeling.

Clarify vision rules.  The true state of the world is a set of layers.
For each cell in each layer, there is an apparent value, a date for
that value, possibly prev values also.  Only need bit if value always
accurately known once discovered.  Elevations and features unlikely
to change, but weather, units, people, material often inaccurate.
May need as many view layers as actual layers, but can often merge
(elevation with terrain, etc).
directly_visible(side, unit)
implies that unit is accurately seen.
chance_to_see{,_on_movement,_on_action,_each_turn}(side, unit)
if always 100%, then is equiv to directly_visible.
Need parms see-xxx-always for each layer.

Define a unit->tracking slot that is a sidemask of sides that are
seeing the unit move around.  (Unit property "trk".)
#define side_tracks_unit(side,unit) (unit->tracking&side_bit(side)).
Define u_track_chance, defaults to 0.
Define u_lose_track_chance, evaluate once/move, once/turn.
If unit being tracked, then updates about unit state go to all
tracking sides.
Track bit would always be set for own units.

Implement storms as very-high-density cloud (>100%?).  Storms cause
accidents and attrition.

Impl constant elevations and temps that don't need a whole layer.
Detect by seeing min == max of terrain types present (and no chance
of terrain changes - test this in general).

Allow some moves to use random mp, be able to specify +/- amounts.
This is mp (and acp?) consumption only, does not affect validity of action.
ut_mp_extra?

Define a notion of hp for bord/conn types, allows for interdiction
and repair.

Side library should be able to allow multiple usages of some members.
If possible now by listing a set of side properties several times,
document as capability.

Define a hallucination chance for some utypes:
(sp-)looks-like u1 u2 -> n% is chance that u1 appears to be a u2
and is recorded as such in a view.
Note that code should ensure that only info about image is displayed
rather than hallucination.

Use a slot (which?) to indicate variation radius of actual reinforcement
position around  given xy.  Default of zero requires to be on actual xy.

Implement ZOC as a layer if any ZOC ranges > 1.

Add a new layer coveralt to indicate the lowest altitude visible
to any unit on the side.  Adjust along with basic coverage.

Add a "facing" bitmask that indicates the directions that a unit is
"facing", or can operate in, add effects of facing vs non-facing.
Come up with a display for this.

Events can have causes that they should be tied to, can use to
enhance displays etc.

Add a (x (symbol <sym>)) to units that can be used to write a symbolic
ref to unit when saving.

Maintain an in-supply bit for units.

Add chance that incomplete units will lose cp (eliminating if cp == 1),
call it incomplete-accident-chance.

To decide about control, see if any units cannot always be controlled
directly, then for those compute the max radius that controlling units
can be in.  If > 1, should define a layer, otherwise check directly
when need to know.

Add a commander property to units, control of units can recurse through
commanders, so unit not under direct control can be under control if
commander is in control range.

Some unit types should be unwilling to break a treaty.
(In some games,)
Should humans have to declare war explicitly?
DoW may not be possible or meaningful in some games...
DoW is agreement by single player doing the declaration, terms are to
treat side as enemy (doctrine), and to hit other side (how often?),
could demand a surrender of some sort.
DoW must be public.
Up to other sides how to respond.
Peace treaty includes terms to nullify DoW.
In general, terms should be able to include refs to other agreements.
DoW can always be rescinded by player alone, make it have morale
consequences?

LOS always sees straight overhead perfectly, so calculations really
figure how how low to the ground is visible at any point.

Could add a bit vector to spottable units indicating which sides
are tracking.

For each unit type, add a property that indicates fate of unit when
side leaves the game - change side, disappear, no change.

@deffn Table @code{people-sabotage-rate??} u m -> .01hp
This table is the attrition rate of a unit in the open in
a cell with people on a hostile [define] side.
@end deffn

DEF_UPROP_I("lockon-chance", u_lockon_chance,
    "chance that unit remains seen when no longer covered",
    lockonchance, 0, 0, 100)
@deffn UnitTypeProperty @code{lockon-chance} n%
This property is the chance that once seen, a unit will continue to be seen
while it is being covered.
Defaults to @code{0}.
@end deffn

DEF_UPROP_I("storage", u_storage,
    "space for materials shared by all types",
    storage, 0, 0, 9999)
DEF_UM_TABLE("material-size-in-unit", um_size,
    "how much space one unit of a material requires in a unit",
    umsize, constumsize, 0, 1, 9999)
@deffn UnitTypeProperty @code{storage} n
This property is a unit's generic space for materials of any type.
Defaults to @code{0}.
@end deffn
@deffn Table @code{material-size-in-unit} u m -> n
This table is the amount by which the given material counts against
the unit's storage space.
Defaults to @code{1}.
@end deffn

DEF_UT_TABLE("capacity-negation", ut_capacity_neg,
    "true if the unit negates capacity of connections of the terrain type",
    utcapacityneg, constutcapacityneg, 0, 0, 1)
[, but some unit types negate the capacity of connections.]
@deffn Table @code{capacity-negation} u t -> t/f
This table is @code{true} if when @var{u} is in the open in a cell
that includes connections of type @var{t},
those connections have no capacity for units.
Defaults to @code{false}.
@end deffn

Implement (or stub) basic goal tests.

Implement doctrine locking.

Terrain types should have a precedence determining which conn/border types
override each other's effects (right now any conn overrides any border).
Should be a property of ttypes.

Side relations could be expressed as a bit vector of what will happen
in various situations.  "wake up if approached", "allow entry", "exchange
view info", etc.  Particular relationships such as trust and control
become particular bit vectors then. (or could do as defcon levels?)

Need a way to have an OB with lots of units, followed by refs to
particular units and modified properties, and read both without
creating any useless units.

@deffn SideProperty @code{respect-neutrality} t/f
@end deffn

DEF_KWD("real-timeout", K_REAL_TIMEOUT, 0)

@deffn SideProperty @code{real-timeout} seconds
This property is the number of (real) seconds to wait before declaring the
side to be finished with this turn.
Defaults to @code{-1}, which waits forever.
@end deffn

@deffn SideProperty @code{task-limit}
This property is the maximum number of tasks a unit is allowed to stack up.
@end deffn

@deffn DoctrineProperty @code{avoid-bad-terrain} n%
This property is the probability that the unit will not enter
unhealthy terrain, even if it delays meeting goals.
Unhealthy means higher attrition and accident probs, materials
consumed faster than replaced, slower movement.
Defaults to @code{0}.
@end deffn

@deffn DoctrineProperty @code{repair-at} n%
This property indicates that when the unit's hp is at @var{n%} of max,
make a plan to repair.
Defaults to @code{50}.
@end deffn

@deffn DoctrineProperty @code{resupply-at} n%
This property indicates that when the level of a
operationally-consumed material is at @var{n%}
of capacity, try to resupply.
Defaults to @code{50}.
@end deffn

@deffn DoctrineProperty @code{rearm-at} n%
This property indicates that when the level of a
combat-consumed material is at @var{n%}
of capacity, try to resupply.
Defaults to @code{50}.
@end deffn

--Setup

Be able to expand country borders by building or occupying outside original
country.
ut_add_people_chance n%
ut_add_people_adj_chance n%

Decide if/how country growth and initial strength should interact.

When opening a game module, add its directory to the list of directories
to search for included modules.

Assign numbers to numbered units after all are read in.  If some instances
of the type are already numbered, start numbering after highest read in.

Add a command-line option to interpret forms supplied on the command line.
Do these after all else read and interpreted and variants done.
Allow both pre-load and post-load (default) forms.

Each side should be able to get different instructions.
Per-side instructions should not be accessible to other sides.

Should use elevation diffs to decide about sloping-type terrain.
Add to basic percentile algorithm.

Add a "spur" phase to road gen that connects to nearest road.

Add a chance for roads that just cross the area from one edge to
another.

If a next dir for a road has a possibility to connect to a unit
of a type that roads connect to, choose the dir to that unit over
any open terrain direction.

Roads should be able to run in non-closer dirs for a small number
of steps.  Should also look ahead to pick overall most favorable
routing.

Player mix test should be allowable_player_mix(assignmentindex),
allows "scapegoating" a particular player if failed - gives
a starting place for interface to fix.

Define parms for variability of initial materials using variation
on fractal percentile synth method.

Liquid adjacent terrain types should always even out to same elevation
(highest or average of all the competing elevations?)
Flooding is always instantaneous if ttypes changed by a unit.
Non-liquid border might or might not be a dike.

Add density of occupants of indep units already placed.  Specify for
both units that have to be occs and others that don't.

Need a way to coordinate all name gen for a single side -
"foo" -> Fooland, Fooard, Fooards, Fooish"  Could also decide colors and
emblem randomly, but wouldn't need to coordinate.
Specify just *one* side name generator, extensions added in a standard
way by an nlang.c routine.
Predefine nonterminals side-name, side-noun, etc in side-namer grammar.

Add "earthlike" generator that borrows code, but is completely wired
to do Earthlike stuff, including a semi-wired set of terrain types
(use extensions to recognize by attributes rather than position,
so that river deltas can be flat and swampy indep of how terrain type
fits with others in a game design).
Use tectonic code at some scales, erosion at others.
Could base calcs on sphere, translate to world grid when done.
Base on all real dimensions, so alt ranges wired.
Parameters are area size/world.circumference for the scale
(assume 100 km/cell if weird circumference),
latitude of area, range of elevations (0 - 10000 meters),
distance from coast (at center of area, allows specifying distance such that
area can be 3/4 land, etc), average temp, average rainfall.
For tectonics, use layers for plate num, move dir, and elevation.
For small-scale, make random ridge/high point, erode down to lowest
or to coast.

Add recorded events that get played when their scheduled time
arrives, so that a city could revolt or disappear at a preset time.
Playing scheduled events should happen after acp/mp calc, but before
players actually get to move.

Add synth method for secret scorekeeper goals.

Use password to match up players when restoring into a different set
of displays.  If no password, then will just accept a different
assignment, perhaps warn for cmdline setup, flag in dialog boxes.

Any terrain-based variation, such as temperature, should check
if need to represent varying values over area, don't need to
alloc layer if not, *but* may need to quickly synth layer if
terrain is added that *does* allow variations.

Should be able to conceal the identity of side until first
encountered (still display progress in turn, helpful to play).
Also not be able to send messages to unknown sides, though
broadcast should still work.

In percentile terrain, map raw to final elevation more smoothly,
computing min/max raw and final, stretching raw range to cover
final range uniformly.

When making units appear, do only units in open directly, then
occupants recursively once transports have appeared.
Similarly for disappearance, but in reverse order.

Add this?  What is it supposed to mean?
DEF_UU_TABLE("can-command", uu_can_command,
    "true if the type can give orders to the other type",
    uucancommand, constcancommand, 0, 0, 1)

--Actions

Add tables material-to-add-terrain, material-to-remove-terrain
(examples are cement to make road, fill material to remove ditch or gully).

Define action "influence" that is like proposed "charm" but more
general.

Allow the construction of bases even when it would be necessary
to bring all units stacked in the cell inside the incomplete base,
in order to make sufficient room.
Entries should be automatic and free.

Add a uu_acp_for_pursuit to give a bonus if the victim is retreating.

Implement acp_for_retreat.  For each direction away from the attacker,
see if (acp_for_retreat + acp) * speed > mp needed to enter cell.
Do for each dir, pick workable.  But first try to retreat into transports
if possible.

Add a separate chance for defender to capture attacker upon counterattack.

Add a material cost um_material_per_<type> and prerequisite
um_material_to_<xxx> for all actions.

Generalized notion of fire interdiction would be useful, could subsume
effects of jammers and suchlike, also if firing is used to represent
aircraft raids, need a way to define interceptors that can reduce
the effectiveness of the raid and the amount of aircraft material
available.

To do < 1 cell/turn speeds, available acp should translate to
occasional ability to move.

Define material-theft-per-contact(u1, u2, r) -> n in combat,
material-loss-per-hit(u1, u2, r) -> n which is material completely lost.
Some could be "resorbed" by terrain?

Some occ types could protect by intensifying counterattack.

Chance to surrender should be higher if damaged.

A mobile unit should be considered surrounded or cornered if adjacent
cells are either impassable or occupied by unfriendlies.  Also look for
impassable borders and passable connections.

Occupants of captured units might get to stay and not change side
if friendliness-to-enter allows it (?).

Detonation's effects should depend on altitude of detonating unit -
compute the "actual" 3d distance.

Define effects of altitude differences on all unit interactions.

Damage to multi-part units could be done by detaching wrecked-type
instead of damaging all parts equally.  Do only if wrecked-type
has appropriate sizes.  Only applies if wrecked-type has equal num
parts to original type.

Could do multi-cell move actions as repn of hex entry until
anything happens that requires a decision - blockage, etc.
example: acp = 1, mp/acp = 10, allows single move of up to 10 hexes.

If a side wins a battle, then side's units involved should gain affinity
for side, lose fear of other side.
On losing side, units lose affinity for own side and increase fear of
winning side.  Nonparticipants also affected, but less so.
Affinity increases by positive acts, fear increases by negative acts.
Betrayals should be detectable, have large effect.
Need some implicit agreements about defense of units on a side,
that players should not violate.

Side action limit should be a distinct value, decremented only for "manual"
activity by player (first action after waiting for input?).

Add a "coordination" action that adds other units to a unit's attack,
with multiplied effect.  Attack action has to look at each coordinating
unit, add effect if able to do so, and take away acp for coordinating
units also.

For variable-commitment combat, attacker effectively sets m% commitment
for self, desires n% from defender.  Defender then chooses between n1-n2%
commitment, where limits set by unit types and m%.
Possible reactions also limited by commitment - defender could disengage
at <10% commitment, say, is otherwise stuck in the battle.
Reactions are counterattack, surrender, withdraw, do nothing special,
these are (mostly) indep of damage.

Commitments default to zero.  If can be nonzero, create battle objects.

If defender counterattacks, then might exchange attacker/defender
in battle, so now defender can decide commit/withdraw.

Response to capture attempt might be to hit capturing unit?
Capture after combat is really a side effect where a unit surrenders
(implies attacking unit might end up doing the surrendering!).

Add loss of material as consequence of combat.
@deffn Table @code{theft-chance-per-attack??} u1 u2 -> n%
@end deffn
@deffn Table @code{stealable-material??} u m -> n
@end deffn
@deffn Table @code{loss-per-attack??} u1 u2 -> n%
@end deffn

Add variable commitment and then constrain it:
@deffn Table @code{attack-commit-min??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-min??} u1 u2 -> n%
These tables are the minimum limits on the initial commitment to a battle.
Defaults to @code{0}.
@end deffn

@deffn Table @code{attack-commit-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-max??} u1 u2 -> n%
These tables are the maximum limits on the initial commitment to a battle.
Defaults to @code{100}.
@end deffn

@deffn Table @code{attack-commit-up-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-up-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{attack-commit-down-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-down-max??} u1 u2 -> n%
These tables are the maximum limits on the change to commitment to a battle.
Defaults to @code{100}.
@end deffn

cxp affects both attack and defense abilities, should define
uu_cxp_{attack,defend}_effect.

Be able to control whether occupants can be attacked directly.

[need general defns for who moves and when during combat rounds]
[could potentiall acquire additional acp if move is discretionary,
also get a level of flexibility about future commitment]

[need combat's effect on tooling? uu_tp_hit_effect, can be positive
or negative (being hit helps recruiit soldiers)
just hit tp randomly as percentage of hp]

@c @deffn Table @code{cxp-hit-plus-max} u1 u2 -> n%
@c This table is the maximum hit modifier for attacker unit.
@c Defaults to @code{0}.
@c @end deffn
@c
@c @deffn Table @code{cxp-hit-minus-max} u1 u2 -> n%
@c This table is the maximum hit modifier for defender unit.
@c Defaults to @code{0}.
@c The actual hit probability equals the basic hit probability, plus
@c @code{experience-hit-plus-max} times fractional experience (i.e.
@c experience divided by maximum experience) of the attacking unit, minus
@c @code{experience-hit-minus-max} times fractional experience of the
@c defending unit.
@c @end deffn

DEF_VAR_I("actions-are-buffered", g_actions_buffered, set_g_actions_buffered,
    "",
    gactionsbuffered, 0, 0, 1)

@deffn GlobalVariable @code{actions-are-buffered} t/f
This variable is @code{true} if all the units of the same priority
must specify their actions first and then execute
them all at once,
rather than deciding and executing before the next unit gets to act.
Defaults to @code{false}.
@end deffn

DEF_UU_TABLE("material-cxp-effect", uu_material_cxp_effect,
    "effect of combat experience on material usage in combat",
    uumaterialcxp, constuumaterialcxp, 0, 100, 9999)
@deffn Table @code{material-cxp-effect} u1 u2 -> n
@end deffn

DEF_UU_TABLE("attack-elevation-effect", uu_attack_elev_effect,
    "",
    uuattackeleveff, constuuattackeleveff, 0, 100, 9999)
@deffn Table @code{attack-elevation-effect} n
Defaults to @code{100}.
@end deffn

DEF_UU_TABLE("friendly-hit-chance", uu_friend_hit,
    "base chance for a type of unit to hit a unit on a friendly side",
    uufriendhit, constuufriendhit, 0, 0, 100)
@deffn Table @code{friendly-hit-chance} u1 u2 -> n%
This table is the chance that a unit @var{u2} on the attacker's side will
be hit accidentally during an @code{overrun} or @code{fire-into}
action.
Defaults to @code{0}.
@end deffn

DEF_UU_TABLE("ambush-chance", uu_ambush,
    "chance that a unit will be able to attack by surprise",
    uuambush, constuuambush, 0, 0, 100)
@deffn Table @code{ambush-chance} u1 u2 -> n%
If @var{u1} attempts to move into a cell containing @var{u2},
then a) if can't co-occupy, this table is the chance that @var{u1}
gets a chance to attack at improved odds(?), or if b) if can
co-occupy, then @var{u1} will enter the cell, then be attacked
as in a).  The ambusher's plan can flag whether the unit
will take ambush opportunities or not.
@end deffn

DEF_UT_TABLE("mp-to-ascend", ut_mp_to_ascend,
    "mp needed to increase elevation or altitude",
    utmptoascend, constutmptoascend, -1, 0, 9999)

DEF_UT_TABLE("mp-to-descend", ut_mp_to_descend,
    "mp needed to reduce elevation or altitude",
    utmptodescend, constutmptodescend, -1, 0, 9999)
@deffn Table @code{mp-to-ascend} u t -> mp
@end deffn
@deffn Table @code{mp-to-descend} u t -> mp
These tables are the mp cost to go from the min possible elevation
to the max possible elevation in the world.
This is interpolated and rounded down.
@var{t} is the type of terrain being left.
Defaults to @code{0}.
@end deffn

@deffn Table @code{ablation} u1 u2 -> n%
This table is the amount of the hit that gets passed through
to the transport's occupants.
Defaults to @code{100}.
@end deffn

@deffn Table @code{stack-ablation} u1 u2 -> n%
@end deffn

Add a way for elevation to screen out detonation effects.

Interleave visual effects with detonation.

Add screen and area flashes as types of movies.

--Backdrop

To decide about revolt, define:
u_[indep_]revolt_chance .01n%
uu_[indep_]surrender-chance .01n%
uu_surrender_range n

Define a "process" object:
(process <name>
  (agents <unit-type(s)>)
  (automated-rate n1)
  (manual-rate n2) ; + acp to do?
  (inputs <material-types>)
  (outputs ...)
  (catalysts ...)
  (terrain-effects ...)
  )
Process agent units are optional.
May want to add "tooling" of units to do a process.

Add a type of random event where a side or group of units can change
to an active side all at once, reflects changing politics, requires
maintenance of reserves, etc.

Run end-of-turn scorekeepers at end of turn 0 (right before first
turn of game)?

Add a min-hp-to-recover that is like hp-to-repair, but applies to
automatic hp recovery.

Add ut_people_supply that is amount of supply gotten by unit if people in
cell are on the same side.

Express need for limited supply as "n turns of supply before starvation"?
Can lead to tough decisions about starving rear areas for sake of major
offensives, etc.

in-length > 0 + ability to transfer from terrain should mean that unit
can get supply from cells other than own cell.  Use to get water from
adjacent land in "voyages".

Should choose side to revolt to by counting
number of units (of same type on each side?).

Siege surrender chance should be distinct from normal surrender chance.

Games should be able to define what size groups can be surrounded,
by radius or number of units.  Default to 1 cell areas.

[need to identify motives for material demand, if type not needed
for actual survival - dyes needed for "art" for example -
might vary between sides/unit types?]
[would need to define generic elasticity of demands,
also the profit-seekingness of a population (vs conservatism, etc)]
[need some notion of credit too?]
[units can effectively forage at some distance, distinguish foraging
from actual production]
[price should go up as material is transported further and further,
and across varying difficulty of terrain...]
[note that as sides, players can't force cell economy but can
encourage it]
[perhaps allow a side to fix a price artificially, let everything
else readjust around it?]
Sides can specify their trading relationship with other sides,
by specifying the ratio of tariff to supply [etc].
[trade relationship is indep of general trust/friendliness]
[some type of agreements might be intrinsically enforceable, such as
exchanges between units that cannot attack or capture each other]
[exchange of material needs to relax fullness rules or be done as
a sort of prim, else might not be able to trade when full]

Do supply lines, display unit's supplier and maybe supply route.
Is there an efficient way to handle this?

To do large elev ranges, use bit 14 to indicate which range,
define a global that gives ratio of ranges.  Also need a descriptor
for text generation.

Add possibility to see some/all of a side's units if one of them is captured.

Weather needs pressure, humidity, calculates new values of these
and also has effects on visibility at multiple levels of atmosphere.
Need to identify effect of each terrain type (and elevation) on each
of these, also specify the rate at which changes occur.
Effects on supply.
Effect on vision, sensing in general.
Each utype has preferred weather, gradual falloff in effectiveness.
Add a generic "violence" value that summarizes wind/storm strength,
relate to unit behavior.
Use season to get avg temp, perhaps regulate motions as well.
Impl via weather phenomena - overcast/clouds, rain/snow, storms/wind,
temperature, humidity (compute value of phenomena, then compute phenomena's
effect on units).
Attrition increased by storms, also chance of accidents (for each accident
type).
Could make some types of terrain temporarily impassable.
Display should show fronts, major storms.
Impl sequence should be fixed weather (weather state), random weather,
seasonal weather, calculated weather.
Implies that player-visible/settable state layers should be implemented first.

Compute a daily temperature cycle based on number of daylight hours etc.

@deffn UnitTypeProperty @code{weather-vision-range} dist
[should be a table so can't see a long ways off from within forest?]
@end deffn

The primary effect of clouds is to make things harder to see.

@deffn UnitTypeProperty @code{vision-cloud-effect} xxx
@end deffn

Be able to play back a recorded sequence of weather during a game.

Distinguish "ideal" material level from "max" level, let
some percentage of material move towards comfortable areas.

Scorekeeper can forbid the saving and restoring of a game, use in
nonsecure situations.

Add a scorekeeper that looks at side view to decide whether player has
discovered something that is to be searched for.  Should be able to
require finding a lost city, etc.

Add option to scorekeeper to run on success/failure of an action
matching given parameters, plus option to run on occurrence of a specified
events, otherwise scorekeeper runs at either beginning or end of turn.
Matching includes side and unit.

Add formal notion of money as a type of material that is global to a side,
has no physical repn.  Materials such as gold can have a monetary value.
Sides can force exchange rates or let float.

Add a "plague" random event/process that randomly spreads and moves around,
use for fires, plagues, floods, etc.
Could track state/progress by material layer or a "severity" layer.
Perhaps use coating terrain for this?

Add random cloud modification process, include random storm generation.

DEF_TM_TABLE("supply-move-rate", tm_supply_move_rate,
    "",
    tmsupplymove, consttmsupplymove, 0, 0, 0)
@deffn Table @code{supply-move-rate} t m -> n
This table says how much of material @var{m}
can be moved through terrain @var{t}
(cell, border, or connection) in each material transfer action.
The actual limit is the minimum of all cells and borders
along the supply route.
A value of @var{-1} allows any quantity to go through.
@end deffn

DEF_UM_TABLE("supply-interdiction", um_interdiction,
    "",
    uminterdiction, constuminterdiction, 0, 0, 9999)
@deffn Table @code{supply-interdiction} u m -> n%
This table is the reduction of supply due
to the presence of an enemy unit of the
given type on the supply line.
A value of @code{100} means that the unit has no effect on supply movement,
a value of @code{0} means that the supply line is completely cut.
Defaults to @code{0}.
@end deffn

DEF_UU_TABLE("spy-see-always-chance", uu_spy_see_always,
    "",
    uuspyseealways, constuuspyseealways, 0, 0, 100)
@deffn Table @code{spy-see-always-chance} u1 u2 -> n%
This table is the chance that if @var{u1}'s spies return information
about a unit of type @var{u2}, then that unit will always be
visible thereafter, as if it were @code{see-always}.
The compromised unit and its side will not be aware that
this has happened.
Defaults to @code{0}.
@end deffn

@deffn UnitTypeProperty @code{spot-movement} t/f
If this property is @code{true},
then the unit's chance to be seen by other sides will be
tested each time the unit moves.
@code{spot-action} implies @code{spot-movement}.
Defaults to @code{true}.
@end deffn

@deffn UnitTypeProperty @code{spot-combat} t/f
If this property is @code{true},
then the unit's chance to be seen by other sides will be
tested each time the unit engages in combat.
@code{spot-action} implies @code{spot-combat}.
Defaults to @code{true}.
@end deffn

@deffn Table @code{see-combat-chance} u1 u2 -> n%
This table is the basic chance to see a unit of type @var{u1} when
in combat with a unit of type @var{u2}.
The location of @var{u1} must be covered by some unit on the viewing side.
This is evaluated for each combat action within a turn.
Defaults to @code{100}.
@end deffn

--Plans and Tasks

Add to move task to distinguish between "move and enter" and "move in open".

In some circumstances (which?), allow plan-tweaking commands to
create and fill in the plan for an incomplete unit.

Add an ability to store and act on dated future plans and goals.
Need to be able to evaluate preconditions for plan, so can do only
if makes sense.

Doctrine and unit plans should include rules about when units should
attack automatically.  Should be careful or will lose units to foolish
actions.

Attack tasks should go after damageable units,
if less than perfect protection, damageable visible occupants.

Check on likely success of resupply task, if dubious, commit to forward
motion.  Consult AI or human prefs?

Defense plan should identify what is defended, and what are the threats.
If no threats, unit just tries to stay healthy.
Defender's search for threats should cover a radius computed from
defender's and ward's positions, areas covered by view, speed of threats
(need to see bombers *before* they reach cities, can attack and retire
before anybody can react).
Threats can be recognized directly, or gotten from AI's list of threats.
A unit is a threat if
1) it can capture or damage the ward
2) it can cut the ward off from supply or other defenders
3) it can hurt the defender
To respond to a chosen threat, can 1) attack the threat, 2) interpose,
3) move the ward, either on own or by carrying.

Do better resupply algorithm.  Unit should decide what materials it
needs, and in what time frame, picks ideal locations to get materials
from, then if at one, waits or transfers supply in.

Do a large sideways move if all immediate directions are blocked.
Only do once or twice before task fails.

"Intercept/defensive" plan directs units to patrol in an area, attacks any
enemy unit (doctrine defines "enemy") that is of a type that can be
attacked/harassed/blocked (ignore types that we can't do anything about!)
Only some kinds of defensive units are interceptors, others are blockers
or kept in reserve.  Blockers interpose rather than attack enemies,
while reserves avoid contact until plan is changed.  Defn of "reserve"
partly depends on attacker, so fighters intercept bombers but ignore
battleships.
Do as explicit decision in general defense plan.

Re-evaluate return if transport moving away too fast.
Calc distance, record as task parameter, check on next
execution of task.  Add AI hook to allow for making transport move
slower or rendezvous with unit needing supplies.
Could have a "home" unit that is preferred if in range, such as
fighters assigned to carriers.  Don't return to transports that
don't have any fuel, unless there is no other choice; check on
each task execution. Special-case
grounding of aircraft if no supply in a base vs starvation of troops
if no food in a base.

Exploration plan should set recon vs invasion type, use to decide
about visibility while exploring.  Recon should attempt to gather
knowledge without being seen.

If can refuel along a route if chosen correctly, subdivide move task
so as to stop at refuel points.

Define a plan type that tracks/shadows units while staying out of sight
as much as possible.  Would have to keep unit within view range but outside
of its view range (and any other coverage, should write something to see
whether a given cell might be visible to enemy), but may have to get
closer to avoid losing trackee.  If unit being tracked seems about to
do some damage, engage instead of shadowing.  May sometimes want to
move to block or slow down trackee's escape.

Need special scenarios to be able to test all plan types accurately,
should set up similar tests for all major parts of planning and AI code,
each should ensure that all the code bits actually get executed.

Plans that fail to decide what to do are a potential problem, should
eventually be replaced, but not too often or else warn about replacement.
Track total usages as well as per-turn usage.
Each successive plan for a unit should have a distinct serial number,
display when displaying plan.  (units never share plans)

All units should get a chance to replan after acp/mp calculated
but before anybody moves.  Should be fast, since nobody can move
while this is happening.
(Interface should be more obvious about this, so less confusion
about turn change.)
Give human players a chance to review plans made by high-initiative units
before irreversibly made (flag review-plans, shows plans of units that
are selected).

What about a task to not just resupply but to prepare for a long trip?
Stock enough to make a crossing, etc.
Check when doing an approach task, may want to push a "fillup" task.

Add notion of "supporting" another unit to doctrine, then unit could wake
up and get involved automatically if combat nearby.
Should specify by type & distance, as well as particular unit.

Do general org chart mechanism, as combined plan/task/AI machinery (formal
limits on action expressed as unit control properties/tables).
Allow promoting any (or restricted type?) unit to be a commander, and
assignment of units to commanders.
Units can have orders to follow cmdr, cmdrs could have utype requisitions
so production automatically goes to them.
(Machine player could use this too.)
Add a display to show how everything relates.
Define a commander_decide_plan(cmdr, unit) or have cmdr make tasks directly?
Each commander should have (or appoint) a deputy unit that will get its
plan data if it dies.  If deputy dies, should work down through orgchart
to find anyone, only giving up if entire group is gone.
"Commander" plan is mod of other plan types, cmdr bit is for coordination.
Cmdr plan includes an "ideal" mix of types to command.
AI uses to set production, human gets told of cmdr unit's needs somehow.

If no AI or display on a side, what should units do?
Will still have doctrine, attitudes, loyalties, so plenty to work from
(include indepside in this but have no side-style coordination?)
Can have and execute plans but no mechanism to change plans
(i.e. can be read in but not altered thereafter - would need to flag?)

Should be able to set a "build rate" that is slower than "fast as possible",
to avoid material depletion.  (i.e. use doctrine to set default rate of
build actions, set actual rate in build task?)
Define as amt of time to wait before starting build of next type (if the same).

Define a "meet" task where transport and occ (or whatever pair
or group) converge on a mutually acceptable place.  Track progress,
give up if not getting closer.

If hit/capture task fails because target has disappeared, offensive plan
should search vicinity of target location for units of matching type.
(But might be better to let generic task planning take over instead.)

Goal to move to an area should be satisfied by moving to nearest spot,
instead of a random point inside.

Add an "engineering" plan type, with subtypes "make-access" and "block-access".
Engineering units build access routes
by adding/removing/modifying terrain, or by building units that serve
only as bridges.  Should be able to build multi-cell/unit chains in
difficult cases.  Examples: could bridge one blocking cell by a) building
a transport unit that ferries, or b) building two connections.  Could
bridge a single blocking border by building a connection or by removing
border.  Want to do this for any cell that is very expensive to cross.
To implement, plan should look for cheapest route assuming that blockage
has been negated, then build bridges for that route.
Engineers should also know how to build roads, do that if road movement
is much faster (such as doubled) than normal movement.

Possibly useful doctrine slots:
    short tasklimit;        /* max length of task queues */
    int respectneutrality;    /* attack neutrals automatically? */
    int trustallies;        /* rely on allies for transport etc? */
    short moverandomness;
    int movestraight;        /* try to move in a straight line? */
    short backtrackinglimit;    /* how far backwards to look for route */
    int unitseveraskside;
    int usemachinestrategy;    /* like setting humanp */
    int wakeintransport;    /* be awake while in transport? */
    int avoidbadterrain;    /* avoid dangerous/unproductive terrain? */
    /* need something generic for event wakeup */
    int lowsupplyreturn;    /* return to base if supplies low? */
    short supplyspare;        /* how close to cut low supplies */
    int repairreturn;        /* return to base for repairs if damaged? */
    int lowammoretreat;        /* run away if ammo is low? */
    int lowammoreturn;        /* return to base if ammo is low? */
    short generosity;        /* how much supply to share with others */
    int expendable;        /* OK to risk destruction in combat? */
    short rearm;
    short repair;
    short resupply;
    short ifnearbycombat;
    short ifnearby[MAXUTYPES];    /* how to react to utype nearby */
    short aggressiveness;    /* general aggressiveness */
    short wakeupinterval;
    short replaninterval;    /* how often to recompute plans */
    short exploreimportance;    /* priority of exploration */
    int exploreedges;        /* explore by going around edges? */
    int buildalways;
    /* something for move order? */
    short maxsubordinates;    /* general limit on number of subords */
    short maxsubordtypes[MAXUTYPES];  /* per-type limit on subords */
      case K_TASK_LIMIT:
        side->tasklimit = numval;
        break;
      case K_RESPECT_NEUTRALITY:
        side->respectneutrality = numval;
        break;
      case K_AVOID_BAD_TERRAIN:
        doctrine->avoidbadterrain = numval;
        break;
      case K_REARM_PERCENT:
        doctrine->rearm= numval;
        break;
      case K_REPAIR_PERCENT:
        doctrine->repair = numval;
        break;
      case K_RESUPPLY_PERCENT:
        doctrine->resupply = numval;
        break;
DEF_KWD("task-limit", K_TASK_LIMIT, 1)

DEF_KWD("respect-neutrality", K_RESPECT_NEUTRALITY, 1)

DEF_KWD("avoid-bad-terrain", K_AVOID_BAD_TERRAIN, 0)

DEF_KWD("repair-at", K_REPAIR_PERCENT, 0)

DEF_KWD("resupply-at", K_RESUPPLY_PERCENT, 0)

DEF_KWD("rearm-at", K_REARM_PERCENT, 0)

--AI

Fix AI so that it obeys real-time limits, and so that if acting as
assistant, timeout isn't ended prematurely.

Fix where town doesn't decide to build - happens when AI is assistant to
display and town wakes up (enemy passing by) but doesn't already have a task.

Add ability to have future goals, ultimately be able to script much
behavior.

Neutral sides should be run by AI, but act only in self-defense,
other AIs should be aware of this.

Hit worth should be the general payoff of one-on-one combat.
First test if combat possible.
bhw = 0 means breakeven.
bhw > 0 means always advantageous, < 0 disadvantageous.
Should account for construction and fuel costs? (is "Strategic worth")
In practice, tactical needs will outweigh the risks involved in fighting
when bhw < 0.
Also account for ability to escape, so less risk?

Designer should be able to toggle flags for mplayer,
force reevaluation etc.

Need better weighting of hit prob vs death prob, also relate to goals,
so unit with low hit prob will still attack another unit if it can win
the game by doing so.  (implies we need to evaluate importance of goals,
nearness to achieving them)

Add a player slot that can be used to set explicit AI goals, would
take precedence over computed goals.

Get goals from a hash table instead of creating anew each time.
Parameters of goal will be read-only.
get_goal(type, p1, ...)
change_goal(goal, newtype, newp1, ...)

Resign if goals (as derived from scorekeepers) are provably unachievable.

Move generic unit analysis tables from mplayer.c to ai.c, so all AI types
can use if desired.  Define/describe as very generic calculations that
are useful convenience caches.  Add more, such as typical time to complete
a particular type of unit.

Write a stdplay.c that is only applicable if game is similar to standard
game (examine set of types, but still need to doublecheck numbers).

Define some sort of generic ai-to-interface display.

--Mplayer AI

If game win is to own a particular type of unit, then set goal to own
one.  If can build, then start building and defend builder.  If unit
known to exist (how?), set goals to find and to capture.  If unit is
mobile, or if might be carried by mobile unit, set up a search pattern,

If countries are large, don't assign all of own country to home front, use
radial or grid theaters instead.

To do patrolling/picketing, space units so that few or no holes in coverage.
In theater being covered, check view dates and send units to update oldest
information - should be closest unit or one assigned to cover.  Could therefore
have a patrolling unit that only moves very little since its view range covers
nearly entire assigned area.  Allowable age of views depends on what sort of
surveillance is avail, how many units are assigned.

Derive acceptable risks from goals - unit that is crucial to game should not
risk self, disposable types can be sacrificed.

Construction calculations should prefer multi-purpose units, but randomize if
values close together.  (Test by making game variants with ultra-powerful
units, should see mplayer shift to building all the time.)
Each goal should be characterized timewise, so mplayer can start builds and
have units ready when goal becomes relevant.

For each type of goal in game, decide which units help accomplish and how
well, which units support indirectly, etc.  Also classify by short/long term
value - short-term is 5-10 turns or 1/10 of game, long-term is length of game.

When exploring world,
use knowledge of country size to optimize search, by spacing out explorers,
not filling in details of terrain until later (is diff, low-priority goal,
maybe subsumed by patrolling).

Prefer to hit or capture transports, especially if easier way to bag
or destroy the occupants.

Keep a persistent layer of "sightings" (or linked list if can be short),
record into when nonempty cell in view array is about to be cleared
during a turn (need hook from vision code).  Date sightings, clear
periodically.

Need a way to estimate units hidden in transports, so can freak out
over approaching transports.

Compute desired number of depot types by calculating the spacing
between necessary to ensure that each can supply another.

If only one builder available, should "timeshare" it properly.
Plan should track what has been produced, reduce preferences more and
more of a type gets built.
Test with old-empire.

Add heuristics to try to build bases at key or useful locations.

If scorekeeper body says something about testing possession on a given
turn, then make occupation a goal from the start.
If occupation goal unsatisfied, assign units to occupy, give each
the same goal, should also attempt to clear the area.
If satisfied, assign unit to defend the area (need to write "how
to defend" code?), possibly patrol around if everything not always
visible.

Speed up theater searches with a for_all_theater_hexes(th, x, y),
that iterates between min/max x and y.

If contacted more than one side, choose a side to concentrate on
(closest most likely), act defensively against other sides (but
still take opportunities).  May need to change emphasis if another
side turns out to be most threatening (tell this by tracking apparent
success w.r.t. each side).

Shift from offensive to exploration if everybody disappears.
Track max # of enemy ever seen and on which turn(s).
Should be persistent in covering area near last spotting of units.

When a unit executes its plan, routines like find_target()
either get a value from AI or search around (implicit "nobrains" AI?).
(AI should have prioritized list of targets composed already and
sorted by theater and goal etc.)

If parts of world view not necessarily up-to-date, need to do pickets
or patrols to guarantee as much coverage as possible. (use view dates)

If moderate-to-high chance of capture by unit surround, put units in
lines and other formations that can't be surrounded easily.

A side should act primarily defensively if it satisfies a goal,
but the game is not over and another side could take away.

Guess at likely theater for contacts, carve out of existing theaters,
reassign/replan *all* units.

Track contacts with other sides on a per-theater basis.

Mplayer should compute which types are mostly likely to be in play
at present, and at future times.  Can look at initial setup, construction
times, etc, and ignore types that can't possibly appear.

Mplayer should attempt to compute numbers of units and material needed
to achieve a goal, to some level of confidence, then set "buildup" plans -
some units explore/patrol etc, then when buildup finished, should plan
large-scale attack, from several directions if possible.  Reserve units
should hang around transports, but not sit on them unless transport protected.

Use people sides to adjust theather boundaries sometimes. (how?)

If chance to surrender by siege > 5%, compute an ideal frontage, minimizes
chance of units getting isolated.

Could do formations by reshaping theaters.  Units mass on edge, don't go past
until mplayer directs an offensive.  If offensive successful, mplayer adds gains to
theater.

If returning to a moving transport, and transport destination is further away,
push a "wait" or "rendezvous" task onto transport's queue.
Rendezvous task should estimate time of expected rendezvous, fail only
if actual time is 1 1/2 longer than expected time.

Be able to change theater size and shape as the situation changes,
let theater develop to optimal size.  (Vague, any real examples?)

For each theater, distinguish
recent vs older sightings, with exponential backoff (1-2 turns ago,
3-5, 6-10, 11-20, etc).

AI should have a chance_to_own_one_of_type(side, side2, u) that the side's
current estimate of the likelihood of the given side2 owning at least one
unit of the given type.

Need special code to know how to defend bridgeheads, recent captures,
etc.  Reduce theater size or focus on immediate vicinity.  Own units
in "enemy" theater (define) should be defended against the most
immediate threats.  Look around for threats or potential threats.
Assign best units to deal with threats.

Have machine player compute general dependency chains for its strategy.
For instance, "need miners to produce uranium from mountains
to build nukes to attack cities".
Should be "lazily" computed, as needed to achieve basic goals.
Strategy code works by calculating a plan that consists of steps
to reach the goals.  Plan is sufficiently detailed when side can
tell each unit what to do, or doctrine has the same effect.
Not always totally deterministic, how does this work?

Unit type analysis should be based on average outcome, plus worst/best-case
outcomes if not maybe not expecting enough action to let things average out.

To estimate materials, scan world, for each unit image, add survival
needs to min est, stockpile - avg operating costs to likely est,
total storage capacity to max est.  Can use actuals for own and allies.
Similar for terrain and population.

Unit first spotting human enemy should disappear as quickly
as possible, might escape before human notices. (exploratory plan only)
Purely exploratory/recon units should generally avoid combat, try to escape
and stay hidden if possible.

Theaters of < 6 cells should be removed entirely.  Find center of theater,
iterate around to a distance of 6 at most, change cell to another adjacent
theater.  Iterate through all theaters, repeat if any too-small theaters
left (might have two two-cell theaters adj, for instance).

To decide when to make bases, do if can create supply, can xfer from
further than units can, can protect units in or near base.

Do base construction as 1) moving to construction site, 2) building, and
3) carrying to final site.  (Must verify that base or parts of base can
be carried.)

When exploring and switching theaters, shift both to inner and outer
theater (actually an abutting theater of any sort).

When enemy unit spotted in a zone, decide if unit is part of larger
group (like a country), what kinds of units might be present (similar,
sessile, etc).
If unit is isolated, decide if it is a threat in any way, if so, make
a goal "enemy gone from x,y" and assign units to work on this goal,
with types and numbers sufficient to the job.  Can borrow from nearby
theater if not too time-consuming.
If group, decide importance (home country being most important),
also assign # units, maybe make theater, track strengths, # units
enroute, and # still needed.
Distinguish units that are dangerous alone and ones that are carriers.
An army that is 2 cells away from capturing a self-unit should have
a maximal threat, since loss of game is certain if threat not counteracted.

Machine player should attempt to infer other sides' strategies.
side->strategy->other_side_analysis[nsides]
If no player on other side, record that other side will not do
anything (and go after to build territory).
If has a display, record as "more dangerous", use as a reason to
ally with other AIs in game.
Sides with displays should also be considered "more unpredictable".
If AIs ally, should be temporary, since game won't end even if all
are allied.

Define an "importance" of activities that gets divvied up among
subcommanders, so overall plans can be set aside temporarily while
individuals deal with immediate threats.

Mplayer code should look for "choke points" that are standard
routes between important places and around obstacles.  Calculate from
world and utypes, share among all machines (don't use if haven't seen
yet!).

Eventually add code to negotiate for neutrality/ally status.

Mplayer should prefer goals with fewest dependencies (prereqs) and
quickest time to completion.  Prereqs mean conditions that must be
true before main goal is worthwhile attempting, but are not formal
requirements - goals are intrinsically self-contained.

Scorekeeper analysis:
if keeping score
  make overall goal to win
  call make_subgoals
else amuse self by being random
if goal is to win
  for each scorekeeper
    if last-side-wins, ... (already done)
    else scan body looking for if's and do's
    (might be too complicated, should announce the fact as a warning
    "too complicated for me, don't know how to play" and drop
    back to simpler if mistaken goals) (or resign?)
    if body is "(if <test> win/lose)"
      make the satisfaction of the test a goal
if goal is to make a side lose
  if can be accomplished by eliminating a side's nonzero-value units,
  set goals to destroy/capture each type
  if not all visible, set goal to find units
    if type can move, goal is to keep info about world up-to-date;
      no random walking, always move to update oldest spots (but
      only in terrain where units could be)
    if type can't move, goal is to have examined all possible
      terrain.

In theater summary, don't print "people" if no people of any type are
present.

--Interface

Come up with a way for update_unit_display to not redraw cell until
all units in cell updated.

Add help node for instructions.

Interfaces should better declare when the game has been ended
arbitrarily (such as by running out of turns).

Change "move-to" long command to be just "move".

Allow typing prefix arg as prefix (or suffix ?) to long commands.

Add way for player to declare if AI is assisting by default, or in
charge by default.  AI decision about whether to end a turn should
also be controllable.  Similarly for resignation.

When turn finished in sequential, update all sides to remove progress
and action amount displays entirely, show only the active player's
progress.

Add idle-timeout, default to 60 secs.  If no player action, and all other
players finished turn, do a finish_turn.

Add some sort of generic "disembark into same cell" command.

Add a tabular form displaying side relationships (trust, willing to draw, etc).

Add a way to get explanations of action and task failures, needed to
explain non-functioning in game designs.

If gdl command is done, all help nodes should be invalidated.
Similarly for many internal arrays (bleah).

Distinguish two kinds of "go to next" consistently - unit that would normally
be queried about next (if current unit not moved so as to require scrolling),
ignore current unit until all others on side have moved.

Autoscrolling should always position so that each adjacent cell to a unit
also shows *entire* adjacent cells, all around.

Lists of units should also be able to display glimpses, just omit data
that is not available (what about names? might be tough to save names
with glimpses)

Need some sort of default grammar used when game designs don't want
to add anything special.
Copy ^0, ... concept for format strings generated by grammars.
Use grammar idea for narrative generation.
Do for actions, notable backdrop events, summaries.
(text disband-narrative
  (self infantry "%2 goes home")
  (u* bomb "%1 dismantles %2")
  )
Match on action args to choose sentence, allow multiple weighted choices
for variety, be able to tailor for each side.
Should be able to do both present and past tense generation.
Routine is describe_thing(side(s), generator, parms[10]).
(Would be generally useful to have a side-to-bit-vector conversion routine...)
"Narrative" different from "message", is past sense, while "message"
describes ongoing things.
Need to do narrative descriptions / events for notable backdrop events
such as migrations, storms, etc.

To choose contour interval for elevation display, get actual elev range
and subdivide into equal intervals, or define a "standard interval"
and multiply if would result in too many lines on map (> 1 line between
cell centers is too much).

Add an imf procedure to compute actual bbox of nonzero bits/mask in an image.

When drawing elevation changes, draw a gray line at cell edges to indicate
the "crease".

To indicate slope, draw center of cell with shape for next smaller mag,
then sloping rects joining adjacent edges of cells, then triangles around
each 3-way meet (for hexes anyway) to fill in holes.

Should not be able to appear to attack if attack not allowed
(arty in ww2-bn for example).

Add designer save option to write only some props of a unit, such as
position, and write as (unit <id> <props>), using name, number or id
as identifier.

Use generic names when summarizing types at a location or in a transport.

Add a side->ready_to_start that each player must enable before actual
game play starts.  Initially false for all sides, mplayer sets when
init done, interfaces enable at player's direction.  Could be button
or implicit when player tries to move.  Note that if multiple humans, and
one tries to move, move will not actually happen until everybody either
tries to move or else clicks on the start button.

When "view" of cell becomes an "exact view", do an update of it.
Redraw cells when coverage becomes zero, always replacing accurate
view with contents of view layer.

Interface should indicate a "move near" plan with a multiple lines
indicating radius, and circle around destination.

Direction cmds in dir of blocking terrain but adj to a slideable
border should cause a border slide. (also for move tasks?)

Linear terrain should be affected by night - draw half-black mask.

Command "ai" toggles between default aitype (first valid type in list
of types - generic mplayer should be first always?) and none, while "ai <name>"
switches to particular ai type.

Add ability to switch to alternate color/icon schemes, such as
winter camouflage for panzer, or military vs pictorial icons.

Add mechanism so that messages get echoed back, for confirmation
of contents mainly.

Fix interfaces so that only one base gets ordered to be built, but lots
of infantry from cities.  (in doctrine, feed to interface? - needs to
be part of default doctrine for all sides in a game!)
For standard, do
(side-defaults (doctrines (u* default-doctrine) ((* @) city-doctrine)))
(doctrine default-doctrine (construction-run (u* 1)))
(doctrine city-doctrine (construction-run (u* 99) (nuke 1)))

When displaying perspective, show top and bottom of "thick" terrain.

For textual commands, interpret <tab>, extend words, etc.

Detect image and image family conflicts/overrides when interpreting imf files,
warn about unless suppressed.

Handle some glimpses as special event types, such as spotting occupants
in a unit, instead of trying to draw on display somehow.
Call glimpse_unit(side, unit).

Don't say, for instance, "independent 2nd wreck" in textual displays,
but just "wreck" - both in topline displays and narratives.

A game design should be able to specify a per-side optimal centering
for the initial view.

Add some kind of sort key control to help info for commands.

Add more help nodes to explain general concepts like acp.
Describe each general concept that is enabled for the given
game, otherwise say "no xxx in this game".

Add table info to help nodes displayed by both first and second indices
(so for ut table, info is listed in a unit node and also in a terrain
node), plus add an additional node for the table alone.  Should table
help nodes be on a separate chain?

For synthesis method help node, add indication of whether each method
was actually run or not.

Add generic commands to go up and down; '-', '+'.
Arg specifies size of change, default is 1/2 of distance to lower/upper limit
on altitude.  Use long name command "alt <n>" to set altitude explicitly.

Allow definitions of images that constitute the border between two given
ttypes, or t1/t2/border combos, etc.  Store in global additional-images
or special-terrain-images
as list where each element is like (<ttype> (<ttype> <dirs...>) ... "image-name")
where first ttype is main cell type, succeeding indicate either linear
in given directions, or adjacent cells of given types in given directions.
image-name is the image or family name to use.
Example? (beach (terrain (ne sea) (half (n sea) (s beach)))
       (border (w nw) river)
       "beach&sea&river-1")

Add "angle" and "facing"  image properties that indicate approximate orientation and
direction being viewed from (side, top, 30 degrees, etc).

Add "dirmask" (or list of dirs) to images that may be used for linear
terrain.

Some images in imf may be precalced for a hex or other shape,
need to indicate specially.

(is sort of done now)
Allow adding a hole or mask to add side emblem to units (plus offset?).
Specify as (image ... (emblem-space x y w h) ...)
Also, each image can declare that an emblem is already embedded, as
... (has-emblem <emblem-name>)... (would still draw actual emblem if
it didn't match the embedded one - leave embedded one, may be useful info)

Need keywords for images to tie less specific images at smaller
scales to more detailed ones - "su-85" -> "tank", etc.

Draw some features by using boundaries, of different appearances.

Need a way to indicate relative precedence of sort keys in list windows.

When in mono, allow choice of small numbers or letters for side, instead of
emblem.

At high mag powers (emblem width < 1/4 cell width), draw people emblems on each
border of hex next to hex with different people.

Define a -h <n> that sets up and waits to get pings from human players.
Like -e <n>.  Kernel only has "wait for <n> remote players", cmdline
does the -h part. -wait <mins> to say how long to wait before going
ahead, also allows players to get impatient and start anyway.
Ideally, the startup host gets a window or command interface
to control the startup process, see who is in, perhaps edit
display specs.
All player specs should be able to add "+n" to adjust advantages,
as in -e 4+2, +2 alone (one mplayer, +2 advantage?)

Players should be able to join above by doing "xconq -join host nnnn [-help]".
Help shows description of game and list of players/sides; say "(available)"
if side is waiting for a player, ask terminal for a side number to join in on.
Serving game must open a socket to listen.  If under X11, program can quit
once display is open; for others, program will continue to run.

Game should be able to spec relative or absolute widths of borders
and connections (used when solid or a pattern).

Should be able to, from cmdline, list available player slots in a remote
game without actually trying to get in.

Should be able to parse dates in commands,
omit parts that are same as current value (such as year).
Date string function should cache stuff, so not always allocing new
strings.
Length of a turn specified as "<n> <unit>" where <unit>
is known to calendar type.
Robustify the base date parsing.

Add a text parser etc for specifying units and types.  parse_[urt]type,
parse_unit should be able to recognize ambiguous matches, either return
# results or report of multiple, be able to process each independently,
put in dialog, etc.  parse_feature to locate geo geatures by name.

Kernel should deliver basic formatting info in help text, let interface
digest - need line breaks, text fill, tabs/tabstops, emphasis/bold (use
^B,^P,^I chars?).  Perhaps some way to name a picture and let interface
fill in actual picture.

Do something in general for reporting destinations, choices are
raw coords, dir/dist, or a dest name of some sort (unit or region).
Useful to have optional map scale to report distances in miles etc?
Examples: "in xxx country" (needs defn of country)
(define gvar "start-area-name" that gives name?)
"NE of country" "E of Foo Bar" "in <region>"
Function is position_desc(buf, side, x, y), where side==NULL means
do for omniscient side,.
also define position_desc_relative(buf, side, x, y, x2, y2).

If info is always accurate and up-to-date, calculate display directly
from state.  If might be unknown at first, but always accurately
known once discovered, keep a bit/piece of info, display from state
if bit is on, else show nothing.  Similarly for info that might
get out of date if observer not present?
If info might be known/unknown and right or wrong, then must maintain
full copy, though can forward to real state if internally known to be
accurate.

Add imf property for additional info about an image. (explanation/derivation,
aimed more at game designers).

Add option to draw contour lines for elevations.
Contour intervals should be based on range of actual elevs, but let
player adjust (perhaps by looking at histogram of elevs).
Game design specifies color of contour lines.
Draw for each of six triangles P0P1P2 in a hex.
Pick two corners with elevs e0 and e1.
For each contour elev ec between e0 and e1
  If e2 > e1, no contours go to the e1e2 side
  If ec between e1, e2
    Draw line to e1e2 interpolation of ec
  If ec between e0, e2
    Draw line to e0e2 interpolation of ec
End
For each contour ec between e0 and e2
  If ec between e0,e1
    Draw line to e0e1 interpolation

Add designer tool to paint theaters for AIs.

In perspective view, displace units by both elevation of cell and their
altitude above it, maybe draw shadow on ground if airborne.
Center unit in cell better (?).
Shade slopes in perspective view according to time of day.

To support multiple natural languages, associate one of several languages
with each side, use to invoke nl-specific nlang.c/help.c routines.
Also have separate command definitions (de-cmd.def, fr-cmd.def, etc)
that interface should be able to use instead.  Each interface, if configured
for it, will have to set up all the command tables, so can be chosen
by each side at game startup.
Would need some sort of function vector setup so as to select the right
set of routines dynamically.

Add interface-independent printable display of all help info.

In printed map, make grid be gray, draw only around known-about terrain.
Draw area edge in light gray if adj cells not known terrain.
Use halftones or patterns instead of bitmaps possibly, add a
color -> grayscal translation process.
General cmd should be "print [window] [width]", where saying "window"
limits to contents of a window (else whole area is printed), and width
gives physical width of map, default is to fit on one page.
Each page should include a legend showing terrain, units, sides, use
up to four columns at bottom of page, run types together in columns to
save space. (Ditto for text/ascii view.)

Common printing code handles layout setup, layout checking, and actual
computation of printed view.  Interface handles any print setup dialog,
plus final disposal of printed view (to file, to print queue, etc).

All interfaces should have all printing methods available.

At end of a turn, display summary/histogram of action/task/plan types
and outcomes. (debugging display?)

Need a general (all-interface) strategy for guaranteeing image
consistency on screen.

Add ability to select direction of perspective view.
Easier if only one of NUMDIRS dirs allowed.

Clarify rules of how immobile units get on transports.

When autoscrolling, interfaces should support a brief delay option
so that players can see the outcome of a unit's last move for the turn.
Can omit if next unit is close by and no scrolling was needed.

Add ability to supply phrases for table row display in help:
"[can create] by default, [except for] base,town,city".
These would be optional non-null args to table display routines.

--Coding

Fix -DSYSV nonsense in SelFile so builds don't break.

Add sanity checks for layers, detect random hits into them by bugs
elsewhere in code.

In lisp.c, be smarter about ptrs to line numbers passed into reader,
do nothing if they're NULL.

Loop through vardefns[] to write out globals instead of including
gvar.def and expanding into separate code for each.

Include a configure option to add/remove PS printing code.

Put some/all info subwin text gen into ui.c or nlang.c, as appropriate.
unit_or_view_info(side, x, y, unit)
cell_info(side, x, y)

unit->side != indepside, always!  (how to check?)

Add a side->allow_entry[s][u1][u2] that says allowability of unit entry
into transports (use for indepside also).  Seed with 1 for all pairs
of types if side is trusted.

When recalculating coverage, detect discrepancies, warn about?

Write goals as separate forms, make xrefs to them.

Record the global state when becoming a designer, be able to write out
deltas only.
Be able to select only particular properties + unit id to write out.

Eliminate USE_CONSOLE from kernel, decide with a runtime flag.

unit_desig should format typename into minimum space, determined dynamically.
Assign chars, if defined, as shortest names, then add longer names to
uniquify names after the first using a particular char.

Allow multiple -L specs for libraries, support list of library dirs to search
for a module.

Collect/write stats on each call to run_game - # unit scanned, # acted,
# actions, # plan executions.  Also classify by type and side.

In initial game analysis, calc which utypes can be on which sides,
stash with side info.  For AIs, also stash guess about first turn
of appearance?

For each scorekeeper, add an internal flag that saves applicability
of scorekeeper, also calc for current turn - if changed, then AI
analysis code should re-run.

Write a search_straight_line(x0, y0, x1, y1, fn) that scans
exact line between places.  Could also do 3d version.

Be able to save individual properties along with ids to match with units.

Add option to save a map rotated, at least by 60-deg increments.
60 left, 1st hextant formula is y' = x + y, x' = -y, etc.

When lots of mallocs being recorded, if full, increase vector by 50% and
copy old records over to new space.

Write dice specs as dice specs, not large numbers.

Use 16-bit indices to an array of pointers to units.

Add multi-player alerts;
multi_alert(msg, sides, [minquorum, mintopass], timeout)
multi_query
update_multi_query_display
interface calls ack_multi_query.

Define zz-s-u-n as cache for shortest name (down to 1 char if possible,
but confusing if only some have one-char names, others are all-but-one
char of name, etc)

Define a can_occupy(...,exclunit) that indicates room if given other
unit is *not* counted (since it will be removed shortly, for instance)

Make a bit vector of allowed sides for each type.

Define performance as a sort of ratio to specmarks, so benchmark game is
known to last 2 minutes on a 100-specmark machine, etc.  Use -R 1, only
"real" games, various mixes of AI, little/no interaction.
Games should include classic, standard, gettysburg, magnusvew, ww2-eur-42.

Doctrine consists of a list of modifications to a single doctrine object
that is final answer (no doctrine relationsships).  Can always clone a
doctrine but then is severed from original; add a routine to merge
matching doctrines together.

Add general check on parameter bounds as given in *.def.  Check while
reading values from forms into tables.

Define foo_text(buf, n, xxx) where n is available space for description,
return actual length of text in buffer.
To get strings, define foo_string(xxx), which returns a 0-terminated string.

For all units on a side, keep sorted by type, keep ptrs to start of each
type, use to index faster.  Could even maintain separate chains for each type.
Define a for_all_side_units_of_type(side,type,unitvar) iterator.

Implement a convex region finder that works by picking random points as seeds
and grows out from those.  Sides have to be "locked" if entire side can't
all grow - combo of locked and unlocked sides allows region to become
parallelogram, triangle, etc.
How should borders and connections affect generic region finding?
Grow from random points until about 3/4 of cells in regions, then scan
down to finish off.  (Could leave single points as "their own regions",
not alloc any region structs.)

General path objects consist of multiple segments, each with start/end
point and a validity test (that can be done at any time).  Also include
a bit with segment saying "shortest" or just "nonincreasing distance".
Should be possible for a path to say "impossible" for some segment??
(consider path that consists of land travel segments plus a sea hop
that needs a ferry of some sort - path is still valid and useful.)

Regions should
point to super-regions, not necessarily contained.  Include bits for
caching connectedness, terrain percentages, etc.  Add region layer to
regular map (each hex can only point to one region, multi-stuff must be
between regions).  Need commands to define and display regions.
Regions never overlap, must subdivide and make subregions be included
in several super-regions.  True for all regions, don't do multiple
"region layers" (unless significantly more efficient?  check stats).
Add region layer for mplayers that need to explore, add to layer
as mplayer sees stuff.

Theory of networked Xconq is that all copies synchronize on actions
and random seeds, then do run_game and get identical results.  Each
program will broadcast its planned actions, then wait until each other
program indicates that it has sent all that it plans to.  When a program
has received "done" from all others, then it can safely execute.

Allow various combinations of multiple- and single-server games.

For any routine in the interface that tweaks in the kernel, have to
siphon it off to the network also.  Do via compiling interface with
augmented calls, so kernel code need not be modified to know about
networking.  On receiving side, input mux includes a decoder that
invokes kernel routines (note that decoder has to know about calls
that not all interfaces actually support, since less-powerful
interface may get kernel-changing messages from more powerful interface).

Build a "skelclient" from skelconq.c and client.c.  client.c includes
a "wait_for_server" that calls run_game or just accepts outcomes and
state changes from the server.

Come up with a way to prove that mplayer doesn't cheat by looking
at structs?  Could have a have a "sneaker" that is always invisible,
never attacked unless mplayer cheats.

Add tests involving two communicating skelconqs with preset port
numbers, use to test networking behavior.  Use a skelconq and Xconq
on Macs to test PPC (or GUSI?)

Add a protocol version number etc so that mismatched versions can't
connect.

Further compress layers by including info about # bits (1,8,16).

Define a "text buffer" object that is variable-size, resizes as needed,
do all printfs into it.
To guarantee integrity, program could display checksum or signature to players
upon startup, so they can agree as to identity of program.

To do play-by-mail games, need to be able to save an optionally encrypted game
and pass along to next player -
player info includes some sort of bit indicating
where to send to. (player-address slot)
Encrypted game should retain game-module form as plaintext,
include a "password" slot, then all numbers appearing at "top level" will be
decrypted, random forms still read normally.
Also must be able to store all notices so other players can see.

Optimize mapping side and unit ids back to objects themselves.  Use hash
table for units, direct table for sides.

For tables, merge index1,index2 slots into one char(?) slot.
Make keyword value a char.
Set up table(type?)s in dynalloc space, sort for efficiency in search.

When saving elevations, always save as 0-based + addend values, doing
multiplier less important.

Use obstacks for building up help text.

Finish writing game compiler, test, collect speed comparisons.

Historical events should always be unique; check for duplications and
complain or avoid creating when restoring a game.

Restrict Lisp syntax knowledge to small part of code, allow translation
to other syntaxes (tcl?).

Keep part of history log on disk rather than in memory, read in to temp
(preallocated) space when saving game.

Add machinery to control size and detail of log, translate old stuff or
some event types into summaries rather than full records.

Kernel should be able to do a system reset - all data structures
and all allocation, so that a different game can be started up.

--Documentation

Filter zz-* out of manual, kwic index, etc.  (Move to hacking.texi?)

List or index commands both alphabetically and by general function.

Document that alternate versions of images are <name>-<n>, n >= 2,
and no need to worry about names that naturally have a -<n> at the end.
Main version should be "best" one.

Document change in meaning of consumption-per-build.

Add manual appendix of symbols that are sorted by class of symbol and then
symbol name.

Add a help node with properties of world (day/night for instance), install just
before unit type nodes.

Add html-ization for manual.

Describe parameters of actions.

In manual, describe each table as UUTable, etc.

Index concepts in manual, index in each chapter as appropriate, so can
trace player/designer/hacker views of concepts.

In hacking.texi, mention that all functions in cmd.def must be
implemented, even if only to complain.

--Testing

Add a compiletime option to measure compute time in microseconds for each
run_game().  Report each turn as histogram of times.

In symbol diff script, check symbols by class (type prop, table, etc)
against appropriate xxx.def file.  Implies no symbols used in both
xxx.def and keywords.def.

Add testing machinery for the graphical interfaces.
Could have AIs play each other on multiple screens.

Add a (quit [if-end]) command to skelconq that exits.  With if-end,
only exits if at end-of-game.

Instead of scanning lib dirs wholesale, make up a list of combinations
of game and variant options to run.

test-lib should run all the useful -g options (use game.dir to collect).

Add a script to discover which modules are never
loaded by any library game.

Set up basic "make check" to run only limited tests on library and standard
test cases.  Should finish in < 1 hour.

Add more directed tests as DejaGnu tests.

Finish adding test images to test.imf.

Add tests for end-of-game handling; win, loss, draw, etc.
Set up some lib games with non- or feeble sides, so one side wins
more quickly, plus heavily lopsided advantages.

To test save/restore of tables, dump out help info separately and
compare after restoration.
Also use compiler and compare its output.

Add a test of external synth program.

Run gdl/doc/all.g consistency tests as part of "make check-gdl".

--Library

Fix where ww2-bn games have two instead one turn of darkness.

Fix ww2-bn to not let ground units capture towns directly from
transports.

Add flag-dutch, flag-slovakia to flag images.

Set standards for names of library files:
case-insensitive, hyphen/underscore equiv, max of 11 chars for
name, 8 chars unique (algo - remove hyphens/underscores, then vowels),
3 chars after dot.  Write a name analyzer/checker, DOS code should
do name reduction algo when trying to open a long name file.
game.dir -> game_dir.txt for DOS.

Establish standard image naming scheme:
[<game>-]<picture>[-<era>]
[<game>-]<function>[-<size>][-<era>][-<side/individual>]
Add to design.texi.

Recognize "color" images that are really just B/W, read/write as B/W.
(mac only??)

WWII scenario should be able to have a "neutrals" side that resists
involvement.  Attempts to attack neutrals should have some consequences.
Spain and Turkey should be neutral, but if attacked, will go over to
other side.  (This should be recorded in the scenario as a preset
property of those AIs!)  AIs on opposed sides should assess value
of capturing side's units vs expense & risk of combat.

For napoleon, make all cities visible, view all units once/month,
but don't be see-all.  Unit positions can be kept more up-to-date
by spies, or say that all units can spy out to 4-5 cells and all
cities are always spotted - so movements around and through are
always known about.

Add more 16x16 panzer images.
Eliminate slope terrain, replace with hilly or rough.

Gettysburg brigades should vary in quality and hp.
For Gettysburg, add movie showing rain descending on field at end of game.
Make unit display say "Kane's brigade (Fed)" instead of "your infantry Kane".

In pelops, try to model Athenian grain trade (abstractly or concretely?).
Add emblems for sides (owl for Athens at least).

Change stdunit so that only towns and cities count, not armies?  Will
require better defensive operations.

If fighters had a low land/takeoff time, then could attack adj bombers
a lot more than now (realistic), but bombers can't escape then, unless
some sort of generic auto-retreat implemented (a good idea).  Auto-retreat
might happen in addition to the hit, rather than instead of the hit.
Refuel should consume part of flying time, but not all, then can
fly many sorties against nearby targets.

Skelconq should examine lib.imf directly during setup, report
on which images were found for the game being loaded if debugging
on, warn if images not found.

Collect more old games, do partial translations (insects, alex).

Image tools should be able to study colors and colorized images
usefully somehow.

Let images refer to colors by name.

Make new world maps that use connections for straits and rivers.
Distinguish navigable/unnavigable rivers?
(extra layers should be optional - could do "ifdef river type")

Add notion of named palettes to .imf files, in form
(palette name color1 color2 ...)
then images can refer to palette by name and colors by index.

Modify standard game to be more resource-bound, supply used up
faster, all units must be kept supplied, need to build strings of
bases to get supplies out to where needed.

Write a ww2-std-pac-42 scenario with Allies (including Soviets?)
vs Japan.  Immediate post-Pearl.

Change ww2-div-pac to include diff sizes of ground units (reg, bde,
marine bn, inf-bn, marine-div).

In ww2-eur-42,
Swiss, Spain&Turkey should have option to be inaccessible, also remove any indep cities.
Sweden inaccessible?  Add 3-5 rows to top of map.
More US cities for balance, more depth to USSR (move existing cities west).

In ww2s-eur-42, add US cities so Allies outnumber Axis 4 : 3 or so, add Axis
town Oslo, Allied town Port Said.

WWII strategic games should have large number of predefined agreements
constraining players.  Add more pre-existing units to all sides.
Fleets should take longer to build?
Add "Axis/Allied minor" sides that include Balkans, etc.

Capturing city in advanced ww2 should cause immediate side change
in cell.
Add handling of oil as resource - inf needs little, armor needs lots,
but only to move.

Define emblems for axis and allied sides in ww2-stdunit.

For Normandy, set up staging areas for German reinforcements to arrive from.
Set German AI to be primarily defensive.

In flattop, gen names like "LC-1", "CA1", etc.
Allow stacking of ships - 4/cell.
Let subs be in same cell as enemy surface ships, let dd's attack there.

In tolkien/ring-quest, most types should be able to enter independents
without capturing.  Hobbits and elves should not be able to capture
anything, but dwarves could capture mines perhaps.  Should riders be
tied to Rohan specifically?

To get the AI to try to capture the ring specifically, define a
scorekeeper that tests possession, Mordor wins if possesses.
Alliance wins if ring no longer exists, can be destroyed by
dropping when on "lava" terrain (only at Mt Doom).

Add a game "Quest".
For one player usually, starts out as a vagabond with limited materials.
Either convert self to higher "rank", or else have improved capability
via experience points and more equipment (but what would "equipment" be
good for exactly?).
Can capture other humans, animals, etc, use as assistants of variable
loyalty.
Terrain is standard.  Include rivers and roads, with significant effects.
Units would be various cities/towns/villages, usual (wandering?) monsters.
Could have a machine-run side that seeks to capture/kill player, like a
police force or army (or assassins?).
Have ships for crossing oceans (but need to "buy" somehow, and if in town,
town should be on coast).
Include weather/seasons with significant effects.
Need unit/material as object of quest, perhaps different kinds for
different games.
(Need to be able to enter/leave neutral places without capturing, but also
be able to accept surrender - perhaps a notion of "if a place is indifferent
to your existence, can interact without combat".  Extend to hostile places
that you can sneak in and out of, though at some risk.)
Should predefine all sides(?), but allow multiple adventurers and only one
monster side - lock this side so players can't take it (but not always?)
To make a game of graduated difficulty, make a long horizontal world, put
player at one end, goal at other, lots of monsters in middle,
tougher ones further away.  (Monsters should move around a little,
but not overwhelm player instantly - could make "electric fences" of
ttypes crossable by player but not monsters, so even fast monsters confined.)
Would look like a string of sausages - 1600x40 world is approx equiv to
40-level dungeon.
Won't be computed incrementally though, but could schedule creation
of high-level monsters to be later in game, make a snowball effect where player
faces huge numbers of monsters if too slow at first.
To make a race game out of this, make a star shape with players at end points
and goal in middle.

Add a game "Medieval Diplomacy" a la Kingmaker.
Each player is a lord/lady with coat of arms.
Few battles, much maneuvering.
More alliance machinery?
Need rules/state for varying degrees/types of alliance, could affect
mutual transport, control, temporary vs permanent gift, etc.
Can move armies around, raise/lower taxes, manage rebellions, wheel/deal.
Players have a chance of dying accidentally or of old age.
Can players be taken prisoner themselves and try to buy their freedom?
(Because if player is killed, possessions revert to neutral or to ally
rather than being acquired by capturer.)
(Need primitive for "exchange", theory is that actual individuals arranging
trade can prevent cheating on the spot, perhaps include a "chance of cheating
success" plus "attempt-to-cheat-p" that each player can set.)
(Be able to have "materials" like age or heat or poison that are deadly if you
accumulate too much? would need a excess-death-chance that is like starvation)

Add a game "Modern War".
Develop modern-day military games, both operational and strategic.

Add a game "Today".
An all-out simulation of the modern world at a 1/2 degree scale,
with each indep country as a side!  Use earth-50km map,
add cities and population to account for everybody.
Would need high-density cities, factories, etc.  Don't worry about size of
game, use it as a test of massive scale.

Add a game "Space Empires".
Like Spaceword HO or GB, based on thinly scattered solar systems with
planets as occupants, ships/cities occs of planets.  Deep space move
very slow (but not less than 1 hex/turn?), but could enter/leave gate
units more quickly if entry of non-adj unit allowed.
Solar systems are always-seen, but would need to explore planets more
carefully (planetary surfaces not plausible tho).
1-month turns??

Add a game "Corporations".
[could make a game based on corporations that have units that are
factories etc, should be able to buy and sell them]

[most elaborate might be to allow corporations to coexist with
countries (what does that mean?)]

Finish the game "Mars".
Settlement of Mars, a la the Kim Stanley Robinson book "Red Mars".
Build underground and domed cities, develop mining etc, try to
control as much of Mars as possible if multiple players.

Add a more elaborate version of "Tolkien".
Alliance A is dwarves, elves, hobbits&Gandalf, Gondor&dunedain, Rohan,
each with own realms (Lorien, Iron Hills, etc),
Alliance B is Mordor, Isengard, Easterners, Southerners,
and indep sides are dragons, trolls, maybe balrogs.
Indeps should have predefined chaotic behavior.
Predefine most units, allow slow production of more.
Places include:
village (Hobbiton, Rivendell) - minimal production, no fortification
town (Edoras, Bree) - minimal fortification
city (Minas Tirith, Barad-Dur?) - has towers and walls, large population
tower (Isengard, Minas Morgul) - fortified place
mine
ruins - defensive advantage only
Types for Mordor should include orcs (group of 100?), wolves (group of 10?),
individual nazgul and trolls.
Hobbits are individuals, elves and dwarves are groups of 20, men & riders
are groups of 100.
Balrogs and dragons are individuals.

--Misc

Period converter should add a default favored-terrain = 0.

Implement Massimo's proposal for morale and feelings:

@section Morale and feelings

@subsection Notes

[@code{feelings} and @code{morale} should be kept orthogonal to
@code{cxp} and acp-debt.]

@code{feelings} (towards each side) are ``affinities''; they can be used
to implement ``loyalty'', ``fear'', etc.

@code{morale} is a sort of ``self-feeling''; it can implement
``heroism'', ``honor'', etc.

@code{feelings} and @code{morale} can also be used to model ``magic
spells'', ``bribes'', ``leadership'', etc.

[remove @code{attitudes-max}, have a feeling towards each side.]

[I think that the following ``status'', ``effects'', and ``charm'' parts
are reasonable; the ``change'' parts are very cumbersome, but I couldn't
come out with something better.]

@subsection Status

@deffn UnitProperty @code{feelings} side-value-list@dots{}
The unit's true feelings towards each side,
including its own side.
Defaults to @code{0} for each side.
@end deffn

@deffn UnitProperty @code{morale} fp
The unit's true morale.
Defaults to @code{0}.
@end deffn

@deffn UnitTypeProperty @code{feeling-max} fp
Sets the range for @code{feelings} and @code{morale} from
@code{-feeling-max} to @code{+feeling-max}.
Defaults to @code{0}, which disables @code{feelings} and @code{morale}.
@end deffn

@subsection Morale effects

All the following modifier add to the given quantity; they are
proportional to @code{morale} and are given at @code{feeling-max}
(i.e., they are multiplied by @code{morale}/@code{feeling-max} first).
They all default to @code{0}.

@deffn Table @code{surrender-chance-morale-modifier} u1 u2 -> n%
[use for sieges?]
@end deffn

@deffn Table @code{base-production-modifier} u m -> n
@end deffn

@deffn UnitTypeProperty @code{acp-per-turn-modifier} acp
@end deffn

@deffn UnitTypeProperty @code{disband-chance-modifier} n%
@end deffn

@code{disband-chance-modifier} requires of course the introduction of
@deffn UnitTypeProperty @code{disband-chance} n%
This is the chance for the unit to disband spontaneously.
Defaults to @code{0}.
@end deffn
Example: setting @code{disband-chance} to @code{0} and
@code{disband-chance-modifier} negative can model samurais: when morale
becomes negative (their honor is spoiled), they have a chance of
disbanding (with @code{disband-message} @code{"commits seppuku"}).

@subsection Feelings effects

All the following modifier add to the given quantity; they are
proportional to @code{feelings} towards the ``other unit's side'' (which
may often be the ``unit's own side'') and are given at @code{feeling-max}.
They all default to @code{0}.

@deffn Table @code{surrender-chance-feeling-modifier} u1 u2 -> n
[use for sieges?]
@end deffn

@deffn Table @code{capture-chance-modifier} u1 u2 -> n
@end deffn

@deffn Table @code{withdraw-chance-modifier} u1 u2 -> n
@end deffn

@deffn Table @code{control-chance-modifier} u1 u2 -> n
@end deffn

@deffn UnitTypeProperty @code{revolt-chance-modifier} n%
(proportional to @code{feelings} towards the ``unit's own side'').
@end deffn

@subsection Morale at creation

Builders may ``transfer'' their morale/feelings to created units.


@deffn Table @code{creation-feelings} u1 u2 -> n
Newly created units start with @code{feelings} equal to n/100 of
creator's @code{feelings}. Defaults to @code{0}.
@end deffn

@deffn Table @code{creation-morale} u1 u2 -> n
Newly created units start with @code{morale} equal to n/100 of creator's
@code{morale}. Defaults to @code{0}.
@end deffn

@subsection Morale changes

They all add to the unit's @code{morale}.
They all default to @code{0}.

@deffn Table @code{terrain-morale} u t -> fp
fp is added after each turn to the @code{morale} of u sitting in t.
Models (dis)-comfort of unit in given terrain.
@end deffn

@deffn UnitTypeProperty @code{acp-low-point} acp
@end deffn
@deffn UnitTypeProperty @code{acp-low-morale} fp
@end deffn
@deffn UnitTypeProperty @code{acp-high-point} acp
@end deffn
@deffn UnitTypeProperty @code{acp-high-morale} fp
If u is left with less then @code{acp-low-point} acp at the end of a
turn, @code{acp-low-morale} is added to its @code{morale}.
If u is left with more then @code{acp-high-point} acp at the end of a
turn, @code{acp-high-morale} is added to its @code{morale}.

They model fatigue/rest effects.
@end deffn

@deffn Table @code{mp-low-point} u m -> mp
@end deffn
@deffn Table @code{mp-low-morale} u m -> fp
@end deffn
@deffn Table @code{mp-high-point} u m -> mp
@end deffn
@deffn Table @code{mp-high-morale} u m -> fp
If u is left with less then @code{mp-low-point} of m at the end of a
turn, @code{mp-low-morale} is added to its @code{morale}.
If u is left with more then @code{mp-high-point} of m at the end of a
turn, @code{mp-high-morale} is added to its @code{morale}.

They model starvation/abundance effects. [use for sieges? m is
@code{"food"}]
@end deffn

@subsection Feelings changes
They all add to the unit's @code{feelings} towards the ``other unit's
side''.  They all default to @code{0}.

@deffn Table @code{transport-feelings} u1 u2 -> fp
fp is added after each turn to the @code{feelings} of u1, enjoing the
ride or the vacation in u2 (which can be a ``resort hotel'').
@end deffn

@deffn Table @code{material-transfer-feelings} u m -> fp
fp is added (for each mp transferred) to the @code{feelings} towards the
side transferring the material m to u.
Models pay, bribes ... (m is often @code{"gold"}).
@end deffn

@subsection Morale and feelings changes

They add to the unit's @code{morale}, to @code{feelings} towards the
``unit's own side'', or to  @code{feelings} towards the ``other unit's
side'', according to their keyword.  They all default to @code{0}.


@deffn Table @code{win-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{win-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{win-other-feeling} u1 u2 -> fp
They are applied when u1 destroys u2.
@end deffn

@deffn Table @code{hit-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{hit-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{hit-other-feeling} u1 u2 -> fp
They are applied when u1 hits u2.
@end deffn

@deffn Table @code{wound-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{wound-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{wound-other-feeling} u1 u2 -> fp
They are applied when u1 is hit by u2.
@end deffn

@deffn Table @code{see-enemy-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{see-enemy-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{see-enemy-other-feeling} u1 u2 -> fp
They are applied when u1 sees a hostile unit of type u2.
@end deffn

@deffn Table @code{see-friend-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{see-friend-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{see-friend-other-feeling} u1 u2 -> fp
They are applied when u1 sees a friendly unit of type u2.

@code{see-enemy} and @code{see-friend} can be used to implement
specialized morale/feeling (anti-)boosters: secret police, preachers,
leaders, dragons, nazguls...
@end deffn

@deffn Table @code{capture-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{capture-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{capture-other-feeling} u1 u2 -> fp
They are applied when u1 is captured by u2.
@end deffn

@deffn UnitTypeProperty @code{change-side-morale} fp
@end deffn
@deffn UnitTypeProperty @code{change-side-own-feeling} fp
@end deffn
@deffn UnitTypeProperty @code{change-side-other-feeling} fp
They are applied when u changes side (own is the ``old'' side, ``other''
the new side).
@end deffn

@deffn UnitTypeProperty @code{revolt-morale} fp
@end deffn
@deffn UnitTypeProperty @code{revolt-own-feeling} fp
They are applied when u revolts.
@end deffn

@subsection Charm

This action can model magic spells, terrorism, psychological weapons,
propaganda, bribes, etc.

@deffn ActionType @code{charm} unit
This is the action that a unit performs to modify the @code{morale} and
@code{feelings} of another unit.  The unit must be visible and within
@code{charm-range} to be charmed.
@end deffn

@deffn UnitTypeProperty @code{charm-range} dist
Defaults to @code{1}.
@end deffn

@deffn Table @code{charm-friend-chance} u1 u2 -> n%
The chance of charming a friendly unit.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-enemy-chance} u1 u2 -> n%
The chance of charming a hostile unit.
Defaults to @code{0}.
@end deffn

@deffn Table @code{acp-to-charm} u1 u2 -> acp
This is the number of acp a unit uses to do one charm action.
Defaults to @code{1}.
@end deffn
@deffn Table @code{charm-consumption} u1 m -> mp
This is the amount
of u1's supply used up in one charm action.
m is usually something like @code{"mana"} or @code{"gold"}.
Defaults to @code{0}.
@end deffn

@deffn Table @code{charm-morale} u1 u2 -> fp
Added to u2's @code{morale} if charm is successful.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-own-feeling} u1 u2 -> fp
Added to u2's @code{feelings} towards its side if charm is successful.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-other-feeling} u1 u2 -> fp
Added to u2's @code{feelings} towards u1's side if charm is successful.
Defaults to @code{0}.
@end deffn

@subsection Relaxation

@deffn UnitTypeProperty @code{morale-relaxation} n
@end deffn
@deffn UnitTypeProperty @code{own-feelings-relaxation} n
(for the unit's own side)
@end deffn
@deffn UnitTypeProperty @code{other-feelings-relaxation} n
(for all the other sides)

They default to @code{100}.
@end deffn

At the and of each turn, the old values of @code{feelings} and
@code{morale} are multiplied by (the appropriate) n/100; then all the
previous modifiers are added; the result is rounded to an integer in the
usual (stochastic) way to obtain the new @code{feelings} and
@code{morale}.

@subsection Missing

@code{revolt-chance} modifier for occupants (and nearby units).  Then,
using with @code{revolt-chance-modifier} and assuming that a
newly-captured unit retains a ``bad'' feeling towards the old enemy, you
will have to guard a newly-captured unit (with your ``secret police''?)
until its feeling towards you improves.

Effects of side behavior: d.o.w. or breaking a treatise should modify
feelings of (certain) units.

Effects of weather.
(end of proposal)

--X11 Interface

Show each player the options that were supplied at startup, as a notice.

Try run_game(3) instead of run_game(1).

Adjust timeout interval to be slower (200ms instead of 10ms)
if no actions were done by run_game.

To do movies, draw a frame and schedule a timeout to draw next frame.

Fix panner view pixmap to not cause crash if multiple displays open
(tmp hack was to disable if multiple displays).

In info window, use fixed fields of 4 chars for each supply type name.

Extend X11 selection of unit types to include multi-char names.

Fix X11 unit type list bitmaps to display with consistent colors.

SelFile should be configured out with disable-selfile, only built
and linked in if configured and present.
Fix SelFile nonportabilities like decl of sys_errlist, etc.

Make imf2x/x2imf translate bitmap filenames and struct names
properly.

Colorize unit icons via u_color().
Allow either use of side colors (symbolically, %1, %2, etc
matching against side color array elts, or by name).

List of unit types should gray out types that can't be owned by
the player.  Add option to eliminate any that can't be in game
at all (designer will need to see all types though).

Players should be able to indicate a willingness to declare a draw.
should display other sides' willingness to draw.

Use special bg pattern or stipple for unseen and grid colors if mono.
(or - support {lt,md,dk}gray on mono displays, in addition to other patterns.

Let imf2x only extract bitmaps whose names match given arg.

Add resource name to request_color, use to override standard
color choices in library.

Add resources:
    -xrm
    -display (for player starting the game)
    -fn, -font (text font only)

Use Xconq.game.<game>.<unit>.{char,image,color} to set per-game colors etc.

Add side->ui->default_draw_units etc to set initial values for each
created map, let these be settable from resources.

Fix drawing to not damage borders or else redraw as needed.
What rules for which should lay on top of which?
Try to optimize so border redrawing not always being done.

Default unit images should include first few chars of name in box,
a la Mac interface.

Allow setting of window subdivisions via resources.
xconq.mapListWidth: <pixels>
xconq.mapNotesHeight: <lines>

Develop a higher-contrast more-visible display of current unit/location.

Typing text into ask_position switches to prompt, reads a textual spec
of location.

Allow terrain color to be two colors, use to colorize mono bitmap
for terrain.
Search for ',' in t_color, fg first, then bg, assume bg is black if
not given.  Need a way to reverse so fg is black and bg colored.

imf2x should indicate progress, never overwrite existing images
(or compare - effectively "move-if-change" behavior)

Use a builtin color matching a color name if possible, otherwise
use the imc definition.

Write image scalers for *2 and /2 size images, compute and cache during
startup.  Shrink rule is 0,1 -> 0, 2,3,4 -> 1.

To describe movement abilities, display both acp and "move range over
a given terrain type", which may be much less.

Non-tiling terrain patterns should be centered in cell on top of another
pattern/color possibly.  How to scale to larger cells?

Never try to auto-calculate hex chars from fill patterns,
but maybe provide a simple tool, goes with tool to build
font from bitmaps?

Font should support terrain pattern inside colored hex - needs to be
precomputed when building the font.  If not avail, still have to draw
twice.

If names displayed on map, use different size (and type?) fonts
for different kinds of units.
Legend fonts should vary with magnification also.

What to do about area painting and dragging?  Turn on pointer motion
events temporarily?  Look at "bitmap" source.

Make the font stuff work again.
Define a family of "xconq" fonts, one (or two?) for each size, pack in
icons, masks, terrain.  Eventually allow more than one font at each size,
in case too many images.  Concentrate on terrain at first...  Keep separate
file with char->image mapping, read in from a standard place at startup.
(Install in program? No, can't update when font is updated)

For event list display, maintain buffer of n lines, each pointing to
event being listed, recalc when window enlarged, etc.
When list[i] selected, display event description plus ptrs
to related events.
Some "events" will be summaries (like total losses),
be able to change amt of summarization.
Observer mask is parenthetical remark.
Include toggles to display events as they come in, and
to scroll map to show where event is happening.

Change setup to use a single popup; list of games and preview at top,
then variants (min size initially, then grow for actual variants),
then player list and buttons.
Constrain to avail screen, borrow code from create_map.
Use cmdline to fill in as much as possible.
Highlight stage as committed to.
Confirm openability of each display when typed in.
Xconq.setup:
Xconq.setup.game:
Xconq.setup.game.list:
Xconq.setup.game.description:
Xconq.setup.game.picture:
Xconq.setup.game.loadbutton:
Xconq.setup.variants:
Xconq.setup.variants.{things}:
Xconq.setup.variants.ok:
Xconq.setup.variants.cancel:
Xconq.setup.players:
Xconq.setup.players.list:
Xconq.setup.players.{aibutton,etc}:
Xconq.setup.ok:
Xconq.setup.cancel:

--Macintosh Interface

Test that maps are properly cleaned up after when closed.

Detect when world size variant can no longer be used (after game
loading and revisit to variants dialog) and gray out.

Instructions menu item should go to instructions node of help
info instead of using a special window.

Gray out resign button if before game start. (?)

Add explicit test for cicn 256, warn if one exists.

Fix to beep if a unit ordered to attack but has no ammo available.
Should also pop up or otherwise make a warning visible.

Fix scrolling confusions in history window.

Fix scrolling confusions in list window.

Add option to display terrain as solid colors if colors are available.

Don't require resignation if quitting while a designer.

Define and use an "erase-in-the-grid" procedure.

Add a "completed units only" option to list view.

Display GPL somewhere at startup.

Don't force update or redraw of windows if clicking a button has no
visible effect (wrong mag for instance).

Don't redraw unchanged scores.

Ensure that "computer" and "face" icons updated when side info changes.

Interp arg to 'P' as number to build, seed from doctrine.
'P' should bring up modal dialog?

In IMFApp, separate "color/mono" from "cqd available" display options.

In IMFApp, "Open..." should preselect imf.dir if exists.

In list, add column that indicates current task.

Disable "give" menu entirely if giving not allowed.

Attach version resources to all components of Mac binary distribution.
Do with MPW script that recurses through all files.

Change of map magnification should automatically set window to user state.

Choice to write statistics file should be preference, or else ask when game is over.

Display range of possible advantages in player dialog, allow setting via
popup or text box as well as up/down arrow.

Add numerical display option for sides, set up 8x8 or 6x8 number emblems.
Also allow larger sizes of numerals (12x12 or 9x12).

Save/restore window setup with Mac interface data, adjusting for
possibility that game is restarting on a different size screen.

Eliminate occasional need to click a second time to get a build to happen.
(Probably because unit hasn't come up in execution order yet.)

Add rubberbanding to world shape/size dialog.

Don't redraw all controls when updating designer dialog.

Support large numbers of sides in setup by adding a scroll bar between list of
sides and the buttons.

Draw side progress bars incrementally when possible.

Describe not-yet-arrived units correctly in list windows.

Check for events between every few rows of drawing, be able to abort or restart
drawing if requested.

Make designer palette into a floating window.

Do mouse-based actions when mouse *released*.

Use unit->uihook to optimize re-selection of units in maps.

Clicking in construction should cause next window back to scroll/hilite
selected unit (or add a button to do?)

Use drag of unit to indicate waypoints of a path, feedback with envelopes
of route and only do waypoints when indicating points outside shortest route.

Be able to double-click in build dialog to set construction .

When laying out list window, precompute widths of columns using max/expected
string widths for type names etc.  Account for width of headers and desired
spacing between columns.

Make pdoc load game and print the full description of it.

Allow multiple units to be selected in list windows.

Express merge by dragging onto unit, express detach by supplying an amount
in modal dialog (awkward, but rare?)

Should be able to zoom or resize side list to show relative standings and
other detail about each side.

Allow for more flexibility in size of emblem relative to unit (a preference?)

Display instructions and notes from multiple modules possibly, need to say
how to do this (explicit "append" directive at end of instructions?).

Implement a progress bar for internals of AI calcs or at least a watch cursor.

Extend construction dialog to include material production.

Build routines to insert a string into a "field" of a list entry,
instead of rebuilding entire entry.

Mark menus to indicate whether any of a group of selected units matches
each item.

Unhighlight forward/backward arrows when no units to look at.

Command-. should be able to interrupt nearly any calculation.

Preferences dialog should have a list of specific setups to choose from
("big screen", "careful play", etc) impl as config-names.  Player config
objects should include Mac-specific flags then...  Dialog can also have
several screens of options.

To display names, make a layer of shorts where each value is location of
cell with the legended object.  Cell itself has access to legend, plus
flag indicating direction and position of beginning of legend.  Then to
erase legend, have to clear each cell that refers to given cell.
Also need to repair legend correctly when another unit passes through it.

When drawing rubberband line for movement, make line heavier for part of
movement that will happen immediately.

When listing units by location, add twist-down for occupants, group stack
members with bar or some such.

Be able to draw more unit info on map window, at least at high mag powers.
Do num parts/hp, mp/acp, in misc corners a la Empire Master.  Unit id would
be useful also sometimes.

Implement both randomly-chosen and cycling image sets for the map window.

Support multiple sounds - ones for attack, hit, death, use diff ones
for shooting, possibly movement noises.
Should be able to define special win/lose sounds (cheers and raspberries),
attach to interface's handling of events from kernel.

Implement images and sound effects for combat (at different scales, so
need to incorporate into imf machinery).

To indicate available movement, change cursor to reflect accessibility
and amount of time needed to get there (ETA) or display in control panel
or elsewhere on map.

Implement doctrine as dialogs examining doctrine objects.
Add button in unit closeups.

Do offscreen drawing for visible map plus part of area around, but need
to calc memory limits so as not to exhaust space prematurely.  Do one
offscreen area/map, precalc size and retain, use individual cell drawing
otherwise.

To draw maps while still allowing events, make an array of rows for each map.
Update event computes which rows to redraw, plus start/end of each (use 0/0
to indicate no drawing needed).   Then in main event-handling loop, if rows
remain to be drawn, do one or a few ("draw rows for 15 ticks") then go back
to wait for event.  Only call run_game when a) all map rows are drawn, or
b) an event comes in from another machine.

Be able to hit key to bring up useful data while rubberbanding, or else have
additional popup with this info.

Add localizations for common languages.

Support distinct images for individual units, via a hook property.
Maintain id->image table (hash table? do sizes as well).

Add a graph window that displays up to 4-5 chosen statistics against time.
Needs choice of what to display and a subset selector for each graph.
Some stats will have records that have been kept, others will start only
when graph is requested, but then keep accumulating even if no longer
being displayed.

Finish perspective display handling.

Add machinery (to MPW version) to build an integrated executable that
doesn't need lib or lib-mac.  Use sed/streamedit and Rez to make
resources from text files, plus renumber so no conflicts with
base resources.

Connect button on splash screen should bring up a transport selection a la Bolo,
with choices of serial, ip, atalk/ppc, and subdialogs appropriate for each.
Player setup dialog then needs a flag for each player to indicate when connected.

--Windows Interface

Add one.

--NextStep Interface

Add one.

--Curses Interface

By default, require manual "return" to advance by turns, if no other
opportunity arose during turn to enter commands, plus add a command
"<n> run" to free-run for up to n turns.

Fix curses interface cursor so not always in bottom corner of screen
on some machines (like sun4).

Fix where extra side is added to restored game because default
side/player is not being used.

Survey->move switch should keep curunit unchanged if occupant.

Check player specs for validity in curses context. (?)

Extend selection of unit types to include multi-char names.

Instead of scrolling to new screen, ask about units already visible,
skipping through others until time to scroll.

To describe movement abilities, display both mp and "move range over
a given terrain type", which may be much less.

When moving cursor modally, maintain some info about what exactly is under
the cursor (use whole info space, put info about what is being
moved in mode line).
Include info about distance from starting position, and support "direction"
cmds to cycle through stack.
Distinguish perm from temp top line data, keep track of each separately.

'D' doctrine, have it bring up textual summary, use textual commands to
modify.

To tweak display, use long name command "show [+-][utn]" to enable/disable units,
terrain, names.

For event list display, maintain buffer of n lines, each pointing to
event being listed, recalc when window enlarged, etc.
When list[i] selected, display event description plus ptrs
to related events.
Some "events" will be summaries (like total losses),
be able to change amt of summarization.
Observer mask is parenthetical remark.
Include toggles to display events as they come in, and
to scroll map to show where event is happening.

Allow putting up a legend to display chars (such as terrain type chars)
in list area.  Bring up via '/' or perhaps option to general help.
(or via 'v' command?)

If can support, add getch() timeout so human can move immediately instead
of waiting for mplayer to finish.  Indicate that mplayer is "thinking"
periodically, need kernel callback (?).

Help topics should be formatted as multi-column list, let arrow keys
move around.

If a savefile is present and no contradictory args found (no -f, -g, -join),
ask the player if they wish to resume the saved game.

Ensure that all stdout/stderr stuff goes into a file so screen doesn't
get scrambled, even with debugging on. (copy Mac code)

Warnings should have a preference to record full text of warning in a file.
Full warning should more data at end of message, then truncate if too big
for alerts.  (If warning recording is on, mention in alerts or somewhere
that additional data is available in a given file.)

--DOS/VGA Interface

Add one.  (Xconq is fundamentally 32-bit code, so not much point in
trying to do anything less than i386 with VGA; in other words, use
DJGPP with libgrx.)